-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: Refactor mock CSI manager #18554
Conversation
and MockCSIManager to support the call counting that csi_hook_test expects instead of separately implementing csimanager interfaces in two separate places: * client/allocrunner/csi_hook_test * client/csi_endpoint_test they can both use the same mocks defined in client/pluginmanager/csimanager/ alongside the actual implementations of them.
to use MockCSIManager like Node_ExpandVolume so we can also test the happy path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
My misgivings: my desire to leave the csi_hook tests mostly unchanged has resulted in a sorta franken-mock where ExpandVolume sticks out as different, since it tracks LastExpandVolumeCall, which I wanted in client/csi_endpoint, whereas allocrunner/csi_hook does call counting.
I get where you're going with that worry, but it also suggests that some of the csi_hook
tests could benefit from checking the last call arguments themselves, and not just the counts. It's not 100% consistent, but it's obvious where someone would add that feature to the mock down the road if they need it later. I'm 👍 to merge as-is.
and MockCSIManager to support the call counting that csi_hook_test expects instead of implementing csimanager interfaces in two separate places: * client/allocrunner/csi_hook_test * client/csi_endpoint_test they can both use the same mocks defined in client/pluginmanager/csimanager/ alongside the actual implementations of them. also refactor TestCSINode_DetachVolume to use use it like Node_ExpandVolume so we can also test the happy path there
and MockCSIManager to support the call counting that csi_hook_test expects instead of implementing csimanager interfaces in two separate places: * client/allocrunner/csi_hook_test * client/csi_endpoint_test they can both use the same mocks defined in client/pluginmanager/csimanager/ alongside the actual implementations of them. also refactor TestCSINode_DetachVolume to use use it like Node_ExpandVolume so we can also test the happy path there
and MockCSIManager to support the call counting that csi_hook_test expects instead of implementing csimanager interfaces in two separate places: * client/allocrunner/csi_hook_test * client/csi_endpoint_test they can both use the same mocks defined in client/pluginmanager/csimanager/ alongside the actual implementations of them. also refactor TestCSINode_DetachVolume to use use it like Node_ExpandVolume so we can also test the happy path there
and MockCSIManager to support the call counting that csi_hook_test expects instead of implementing csimanager interfaces in two separate places: * client/allocrunner/csi_hook_test * client/csi_endpoint_test they can both use the same mocks defined in client/pluginmanager/csimanager/ alongside the actual implementations of them. also refactor TestCSINode_DetachVolume to use use it like Node_ExpandVolume so we can also test the happy path there
Right up front: I have mixed feelings about this. Let me know if I should just throw it out 😋
Instead of separately implementing csimanager
interfaces in two separate places:
they can both use the same mocks defined in
client/pluginmanager/csimanager/
alongside the actual implementations of them.
My misgivings: my desire to leave the csi_hook tests mostly unchanged has resulted in a sorta franken-mock where ExpandVolume sticks out as different, since it tracks LastExpandVolumeCall, which I wanted in client/csi_endpoint, whereas allocrunner/csi_hook does call counting.
I'm not thrilled with the result... I might prefer proper call recording across the board, which could also cover call counts, but I should probably move on to the next priority that needs attention. If the state of this is distasteful, I'd be willing to just throw it away. 🤷